왜 lambda여야 했는가
EC2가 아닌 람다를 택한 가장 큰 이유는
경제성 및 운영 현실성 때문이었습니다.
개요
실시간 랭킹 시스템의 경우, 지속적인 연결 유지와 이벤트 전송이 중요하다고 판단하여 EC2 기반 구조로 배포를 진행하였습니다.
반면 스트리밍 및 다운로드 시스템은 실시간 양방향 통신보다는, 파일 제공과 제한적인 요청 처리가 중심이 되는 구조였습니다.
따라서 해당 시스템에서 EC2는 항상 서버를 유지해야 한다는 점에서 운영 비용 대비 비효율적인 선택에 가까웠습니다.
결국 Lambda를 선택한 가장 큰 이유는:
- 유지보수 부담 감소
- 서버 직접 관리 최소화
- 요청 기반 과금 구조를 통한 경제성
등을 함께 고려하였기 때문입니다.
[1]Cold Start 문제는 존재하였지만, 해당 시스템은 24시간 구조가 아니었기 때문에 매장 운영 종료 시간대에 재배포를 진행하며 비교적 안정적으로 관리할 수 있었습니다.
왜-ec2가-아니라-lambda였는가
채택 이유
Signed URL 방식을 채택한 가장 큰 이유는, 바로 접근 자체에 제약을 둘 수 있기 때문입니다.
기존처럼 고정된 URL을 직접 노출하는 방식이 아니라, 서버에서 제한 시간이 포함된 임시 URL을 생성하여 전달하도록 구조를 변경하였습니다.
이를 통해:
- 일정 시간이 지나면 자동 만료
- 외부 공유 링크의 지속 사용 제한
- 저장소 직접 접근 최소화
- 다운로드 흐름에 대한 서버 제어 가능
등의 효과를 얻을 수 있었습니다.
또한 해당 방식은 프록시 기반 파일 전달보다 서버 부하가 훨씬 적었으며, Lambda 환경에서도 비교적 안정적으로 운영 가능하다는 장점이 존재하였습니다.
특히 해당 프로젝트는 전국 단위 매장에서 실제 사용되는 구조였기 때문에, 이론적인 완전 차단 구조보다는:
- 운영 비용
- 응답 속도
- 유지보수 난이도
- 실제 사용 환경에서의 안정성
을 함께 고려한 방향이 더욱 중요하다고 판단하였습니다.
구조 변경 과정
최종적으로는:
- 사용자가 다운로드 요청
- Flask 서버에서 권한 검증
- Firebase Storage Signed URL 생성
- 제한 시간 포함 URL 반환
- 사용자는 제한 시간 내에만 접근 가능
형태로 흐름을 변경하였습니다.
이 과정에서 중요한 것은 단순히 URL 생성 기능 자체가 아니라, "접근 권한의 수명을 짧게 가져가는 것"이었습니다.
실제 운영에서는:
- 지나치게 긴 만료 시간은 사실상 공개 링크와 유사해지고
- 너무 짧으면 사용자 경험이 불안정해질 수 있기 때문입니다.
따라서 서비스 특성과 실제 사용 흐름을 고려하여, 현실적으로 안정적인 만료 시간을 조정하는 과정도 함께 진행하였습니다.
[2]보안은 단순히 강한 구조를 사용하는 것보다, 실제 운영 환경에서 유지 가능한 구조인가가 더 중요하다고 생각합니다.
해당 프로젝트에서는 "완전 차단"보다는:
- 제한된 접근
- 짧은 권한 유지 시간
- 서버 기반 접근 제어
를 통해 현실적인 운영 안정성을 확보하는 방향을 우선시하였습니다.
각주
Cold Start 문제는 존재하였지만, 해당 시스템은 24시간 구조가 아니었기 때문에 매장 운영 종료 시간대에 재배포를 진행하며 비교적 안정적으로 관리할 수 있었습니다.
보안은 단순히 강한 구조를 사용하는 것보다, 실제 운영 환경에서 유지 가능한 구조인가가 더 중요하다고 생각합니다.
해당 프로젝트에서는 "완전 차단"보다는:
- 제한된 접근
- 짧은 권한 유지 시간
- 서버 기반 접근 제어
를 통해 현실적인 운영 안정성을 확보하는 방향을 우선시하였습니다.